1. Field of the Invention
The present invention relates to management of Internet Protocol (IP) addresses used by network nodes. In particular, the present invention relates to tracking usage of IP addresses back to network nodes, for example based on the IP addresses having been used for illegal activity such as Denial of Service, virus/worm attacks, distribution of spam (unwanted e-mail), or for tracking usage of IP addresses relative to Quality of Service policies, or to monitor node mobility.
2. Description of the Related Art
Network administrators have encountered a dramatic increase in the number of Denial of Service (DOS) attacks and spoof packet attacks in the last few years. It has always been difficult to identify the source of the attacks, namely the individual host computer that is specifically responsible for the attacks. In particular, IP-based networks typically include resources for maintaining network operations; however, network state is not preserved for future analysis. Hence, if an attack is detected, there is no audit trail preserved that enables an authoritative source to trace the origin of the attack with sufficient information to identify a specific individual user.
In addition, enforcement efforts in protecting against various forms of abuse are frustrated due to the untraceability of the network address, because there is no authoritative technique for correlating a network address to a user identity.
Monitoring of link layer addresses (e.g., MAC layer addresses) is insufficient, since the link layer information that could be used to identify the origin of the attack is lost after the packet has passed the first hop router. The IEEE 802.1x standard provides for layer 2 authentication but does not specify methods for collecting layer 3 addressing information. Further, efforts to block a link layer address do not scale well in deployment; link layer addresses also can be “spoofed”, and computers may have multiple network interfaces having respective link layer addresses, for example a first MAC address for a wired IEEE 802.3 interface, and a second MAC address for a wireless IEEE 802.11 interface.
Further, the link layer is not necessarily tied to the IP network layer; hence, a user that is attached by a link layer can send packets onto the network with an arbitrary IP network source address, for example dynamically-allocated network addresses based on Dynamic Host Configuration Protocol (DHCP) or dial-up services. This arbitrary network address utilized by the user also is typically the only reference available to an enforcement entity to identify the requesting source.
Attempts at providing authentication services have addressed assigning an authenticated IP address to a user, such attempts fail to address the problem that a malicious user may still use an unassigned address. Examples of existing authentication services include Remote Authentication Dial-In User Service (RADIUS) as described in the Internet Engineering Task Force (IETF) Request for Comments (RFC) 2865, available at the IETF website address “www.ietf.org/rfc/rfc2865.txt”. The RADIUS authentication records an IP address having been assigned to a user. In particular, a user of a dial-up PPP service may connect to a service via an identifiable dial-up port (e.g., “41”), provide authentication information including user identifier (e.g., “john_adams”) and password; hence, the RADIUS service can authenticate the user identifier (e.g., “john_adams”) based on the password, and correlate the authenticated user identifier to the dial-up port “41”. The RADIUS service also will determine that the PPP negotiation has supplied the user a prescribed assigned IP address “X.Y.B.C”; hence, the RADIUS service can store in its internal database that the assigned IP address “X.Y.B.C” was assigned to user “john_adams” on the dial-up port “41”.
As described above, however, the existing systems have monitored only the IP address that have been assigned to a user, and not necessarily the actual IP addresses that are used by the user. However, the same enforcement issues arise because a source node may use an alternate IP address (e.g., “Y.X.Q.R”) that differs from the IP address having been assigned to the user (e.g., “X.Y.B.C”).
Although application-level proxy resources and Network Address Translator (NAT) devices are able to utilize proxy authentication to associate user names to IP addresses, there is no guarantee that all data traffic will pass through the application-level proxy resources or the NAT devices. Hence, a rogue device can circumvent the application-level proxy resources and NAT devices to avoid detection.